För företag och organisationer som har behov mer komplexa regler för dokumenthantering, exempelvis ärendehantering eller annan processtyrning, finns Content Studio Workflow Server. Produkten gör det möjligt att skapa informationsflöden som bygger på roller, att-göra-listor, seriella eller parallella flöden, dynamiska flöden styrda av villkor och innehåll etc.
I ett klassiskt arbetsflöde passerar informationen/ärendet ett antal olika steg eller dokumentstatus, exempelvis Nytt ärende, Under analys, Under åtgärd, Åtgärdat och Avslutat. I Content Studio Workflow Server kan ett godtyckligt antal steg definieras och för respektive steg kan arbetsuppgifter utdelas till medarbetarna. Content Studio Workflow Server hanterar automatiskt all notifiering, behörighetskontroll och publiceringsmekanism.
Med en effektiv arbetsflödesmotor minimeras det manuella arbetet med att överföra ansvaret till "näste man i ledet", informationskvaliteten höjs och arbetet styrs upp av uppsatta regler. Rättigheter och arbetsuppgifter såsom att granska, skapa, skriva, komplettera, godkänna, bedöma eller delegera, styrs av arbetsflödet.
En arbetsflödesmotor kan implementeras effektivt inom ett antal områden, exempelvis:
- Ärendehantering
- Ledningssystem
- IT-Support, Helpdesk
- Dokumenthantering
- Beslutstöd
- Inköp
- Rekrytering
Content Studio Workflow Server integreras mycket väl med EPT-tekniken i Content Studio vilket ger Workflow-medvetna redigeringsformulär. Att utveckla exempelvis ett ärendehanteringssystem är betydligt enklare med Workflow Server än med traditionell programmering.
Sätta upp arbetsflöde
Att skapa ett arbetsflöde i Content Studio består sammanfattningsvis av följande moment:
- Skapa en arbetsflödesdefinition (Workflow Definition)
- Applicera definitionen på önskad dokumentkategori.
- Om kategorin är av typen EPT-dokument kan redigeringsformuläret kompletteras med Active Scriptingkomponenter som interagerar med arbetsflödesmotorn.
Definitioner och terminologier
Nedan följer en kort beskrivning av flödesdefinitioner och terminologier.
Workflow definitions
A workflow definition defines the workflow itself. It contains a large number of settings and parameters that describes all steps, roles, rules etc. Workflow definitions (WF Definitions) are stored in a central repository accessable for administrators. Normally only administrators can create/edit workflows.
WF Definitions can be applied on one to many document categories:
Workflow implementation
A workflow implementation is a connection between a workflow definition (above) and a XML document category in Content Studio. When a category has been configured to utilize a workflow (ie. workflow definition), all new documents or revisions in the category will use the selected workflow.
Workflow instance
When a new document is created, or when a new version of a document is created, a workflow instance will be applied to the document. The workflow instance is a copy of the workflow definition combined with information about the document, the category and the roles and members defined on the category. The workflow instance will be attached to the document until the workflow completes or terminates. All information about user actions and content changes is stored in the workflow instance.
Roles
A central definition in a workflow definition is Roles. Roles can contains a number of member (users) who can participate in the workflow process and perform different tasks. Typical roles are 'Authors, 'Reviewers' and 'Approvers'. Members in roles, ie users, can be defined in the definition itself or on the category implementation, or be selected by the workflow owner.
Roles (and their members) are later assigned to the workflow steps.
Members
Users defined in a role are called Members. Members can participate in workflow steps and perform different tasks.
Participants
Users who actually participate in a certain step, and therefore have tasks assigned on them, are called participants. Participants are normally defined as members, but in some workflows participants can be selected by the workflow owner.
Steps
The steps section in a workflow definition is probably the most important part of the workflow. A workflow normally consists of 3-5 steps describing the process in which content is created, reviewed, modified, approved and published. Typical steps are 'Authoring', 'Reviewing' and 'Approve'. In a workflow you can define as many steps as you need.
Types
Steps can be of 3 types:
- authoring - participants can edit content
- reviewing - participants can review content and normally not edit content (configurable)
- approval - participants can approve/reject content and normally not edit content (configurable)
When you design a workflow you can define any number of steps and you can create step sequences that combines authoring, reviewing and approval.
Document Status
When a step starts, completes, is cancelled or due, the workflow status changes to the value defined in the definition. Typical statuses are 'New version', 'Sent for authoring', 'Authored', 'Sent for review', 'Reviewed', 'Sent for approval', 'Approved' and 'Rejected'. Document status are defined using the attributes csbeginstatus, cscancelstatus, csduestatus, csdeclinestatus, cscompleteyesstatus, cscomletenostatus
Completion rules
A step has always a completion rule defining when the step is considered as complete. Completion rules includes
- all - all participants must complete their task
- X % - X % of the participants must have completed their task
- X - X of the participants must have completed their task
If the completion rule is forfilled, the step result will be completed. Normally the step result is evaluated everytime a task status changes and therefore the step can be completed BEFORE all participants have completed their tasks.
If evaluation should occur AFTER all participants have completed/declied their tasks, the 'allmustparticipate' setting can be used.
Step result
When a step has been run the result will be set to any of the following:
Result | Description |
---|---|
Complete/Yes | The step was completed according to the Completion Rule. If the steptype is 'approval', the step/document was approved. |
Complete/No | The step was completed according to the Completion Rule. If the steptype is 'approval', the step/document was rejected. |
Due | The step was due because the step was not completed before due date. |
Cancelled | The step was cancelled because the workflow owner withdrew/cancelled the step. |
Serial or parallell flow
Tasks assigned in a step can be assigned to participants in parallell or in serial:
- Parallell - all participants will receive their task/notification at the same time.
+ fast task assignment and faster response
- Risk of task-SPAM depending on rule - Serial - participants will receive their task/notification when the previous participant
has completed or declined their task
+ Accurate task assignment independent of rule
- Slow task assignment
Selectable members
Members participating in a role applied to a step, can be predefined or selectable by the workflow owner. This is configured in the 'selectable' tag:
- no - participants cannot be selected by the workflow owner. Only default role members will participate
- yes, a role member - a single member of the role can be selected
- yes, role members - any number of members of the role can be selected
- yes, a user - a single domain user can be selected
- yes, users - any number of domain users can be selected
Runs
The steps defined in the workflow can be executed more then once depending on the rules in the workflow.
Each time a step is started, a new Run is created. The Run contains information about participants, tasks, due dates, task instructions and more.
The Run segment of the Workflow definition is empty when the instance is created. Before a step is started, the Runs segment is created and filled with run-data.
Tasks
Tasks are "to-do-items" attached to steps and participants. In a step, a participant can have a task assigned on him/her. The participant is normally notified by either mail or by the integrated to-do-list in CS.
When a participant completes or declines the task, or when the task is due or the step cancelled, the step result is evaluated according to the Completion rule.
# Participants | Completion Rule | Actions by participants | Result/approve status | Comment |
---|---|---|---|---|
4 | All | 4 Approve or Return to WF owner | Completed/Yes | |
4 | All | 1 Decline | Declined | |
4 | All | 1 Reject | Completed/No | |
4 | 1 | 1 Approve | Completed/Yes | |
3 | 50% | 2 Approve | Completed/Yes | |
3 | 50% | 2 Reject | Completed/No | |
4 | All | Task is due | Due |
Notifications
CSWF integrates with the CS Notification Engine by automatically sending to-do items to step participants. The notifications sent by CSWF contains customizable titles/messages for each step which gives the workflow designer the possibility to create pedagogical notifications. The messages sent can be built up by both static and dynamic content. For dynamic content CSWF supports a large number of variables and constants.
When a task has been completed it will automatically be removed by CSWF from the to-do-list.
Workflow Owner
Every workflow instance is owned by a user. In CSWF this user is called the Workflow Owner, or wfowner. Normally the wfowner is set to the document owner (creator) when the document is created, but the wfowner can be changed by the wfowner himself, by the administrator or by workflow logic. For example, the wfowner can be changed when a step starts and the ID of the owner can be defined in the XML.
Normally, the wfowner controls the workflow and have permission to withdraw or cancel steps. The wfowner can also terminate the workflow. The workflow owner can have permission to pick step participants.
Enabling/disabling steps
Steps is normally enabled and accessable for the wfowner. An enabled step can be started by the wfowner. In complex workflows a more controlled flow can be set up using the 'enablinglogic' step setting. This setting controls how and when a step will be enabled or disabled. CSWF evaluates the content of the enablinglogic setting and if the result is True, the step will be enabled.
WFXML
For XML-documents managed by a Workflow a number of new CS XML-tags will be added and updated during the workflow cycle:
Element | Description | Example |
---|---|---|
WF_Owner | Security descriptor for workflow owner | S-1-5-21-2060480078-1251939488-620655208-1007 |
WF_CSStatus | Current workflow status (in clear text, as definied in the workflow definition) | Sent for review |
WF_Status | Workflow status | Running |
WF_LastRunStarted | Date/time when the last workflow step was started | 2004-06-01 |
WF_ActiveRunDueDate | Date/time when the current step will be due | 2004-06-02 |
WF_ActiveStep | Name of active step | On review |
WF_Authors | Userkeys for all participants who has been part of an authoring step | AAAAA5, AAABB6 |
WF_AuthoredBy | Userkeys for all participants who has authored content in an authoring step | AAABB6 |
WF_Reviewers | Userkeys for all participants who has been part of reviewing steps | AAAAD5, AAABE3,BADA2 |
WF_ReviewedBy | Userkeys for all participants who has reviewed content in an authoring step | BADA2 |
WF_Approvers | Userkeys for all participants who has been part of an approval step | AAAAD5, AAABE3 |
WF_ApprovedBy | Userkeys for all participants who has approved content in an approval step | AAABE3 |
Workflow settings
General workflow settings can be set using the wfsetting attribute:
- adminsetwfowner - an administrator can change workflow owner
- keepwfowner - the workflow owner will remain between document revisions
- ownersetwfowner - the current workflow owner can change workflow owner
- singlerevisiononly - only one document version is allowed.
- mailonwfownerset - a mail will be sent to the new workflow owner when ownership is changed
Steps settings
For each step in the workflow different settings may be applied using the stepsettings attribute (multiple values must be comma separated):
- approverscanedit - in an step of type approval, the participants can edit content
- allmustparticipate - in a serial flow, all participants will participate even if the step completion rule has determined that the step result is negative or the step is declined
- ownercanedit - owner can edit even thought the workflow is in a review or approval stage
- returnandcompleteondue - if the step is due (timeout) the step will automatically be completed (yes)
- returnandrejectondue - if the step is due (timeout) the step will automatically be rejected (no)
- returnondue - if the step is due (timeout) the document will be returned (User action returntowfowner)
- copyparticipantsfromlastrevision - participants in the step will be kept between reviwions
- copyparticipantsfromlastrun - participants in the step will be kept between runs
- csapprove - if the result of the step is completed yes, the document will be approved (and published) in content studio. The workflow will also be completed.
- autocomplete - the step will automatically complete, approval step type not supported
- ownersetwfowner - the current workflow owner can change workflow owner
- reviewerscanedit - in a step of type reviewing, the participants can edit content
User actions
During a workflow the client (user) can perform different tasks that affects the workflow status and flow. These tasks are called User Actions and are executed through Active Scripting components such as the WF Button component and the API.
- terminateworkflow - this action will terminate the workflow. The action is only available for the wfowner (and the administrators)
- sendforauthoring - the workflow will initialize a step of type authoring. The action is only available for the wfowner and when no step is active.
- sendforreview - this action will initialize a step of type review. The action is only available for the wfowner and when no step is active.
- sendforapproval - this action will initialize a step of type approval. The action is only available for the wfowner and when no step is active.
- cancelauthoring - this action will cancel a running step of type authoring. The action is only available for the wfowner and when an authoring step is running.
- cancelreview - this action will cancel a running step of type review. The action is only available for the wfowner and when a review step is running.
- cancelapproval - this action will cancel a running step of type approval. The action is only available for the wfowner and when an approval step is running.
- returntowfowner - this action will complete a task. The action is only available during a running step and only available for step participants that has NOT completed their task.
- reject - the action will complete a task with a negative response (=reject in approval steps). The action is only available during a running step and only available for step participants that has NOT completed their task.
- approve - this action will complete a task with a positive response (=approve in approval steps). The action is only available during a running step and only available for step participants that has NOT completed their task.
- decline - this action will decline a task (=refust). The action is only available during a running step and only available for step participants that has NOT completed their task.
- setparticipants - this action will set participants for a certain step. The step may not be running.
- changewfowner - this action will change wfowner. The action is only available for the current wfowner (and administrators if the workflow setting adminsetwfowner is used)
Workflow definition details
Below is a description of the xml-tags in a typical workflow definition. Some of the details are set when the workflow is instanciated and used and are read-only. Read-only items are in gray.
Workflow Section
This section defines general workflow settings
Field/attribute | Description | Example |
---|---|---|
workflowname | Name of the workflow | CS Default Workflow |
description | An optional description of the workflow. Usefull in notifications and in instructions to the participants. | This is a typical author, review and approve workflow |
instanceguid | Read-only. GUID for instance. Set when workflow is instanciated | {1C35029E-6929-4F65-B6EF-093FB4661D56} |
instancedbysid | Read-only. Security Descriptor (SID) of user who instanciated this workflow. | S-1-5-21-2060480078-1251939488-620655208-1007 |
documentid | Read-only. Document ID for which this instance applies. | 23141 |
categoryid | Read-only. Category ID in which the document resides. | 51 |
categoryname | Read-only. Category name in which the document resides. | Job Applications |
revision | Read-only. Document revision | 3 |
wfsettings | General settings for the workflow definition |
|
instancedate | Read-only. Timestamp when instance was created | 2004-06-18 15:31:00 |
firststepdate | Read-only. Timestamp for first step action | 2004-06-18 15:31:08 |
lastactiondate | Read-only. Timestamp for last user action | 2004-06-18 15:32:03 |
lastrunstarted | Read-only. Timestamp when active run was started. Blank if no active step. | |
lastactionparticipantsid | Read-only. Security Descriptor (SID) of user who last perfomed any kind of action in the workflow instance | S-1-5-21-2060480078-1251939488-620655208-1007 |
lastactionparticipantname | Read-only. Security Descriptor (SID) of user who last perfomed any kind of action in the workflow instance | Åström Niclas |
completeddate | Read-only. Timestamp when workflow was completed. Blank if not completed. | 2004-06-18 16:13:02 |
activestep | Read-only. Name of current active step. Blank if no active step. | For review |
activesteptype | Read-only. Type of active step. Blank if no active step. |
|
activerun | Read-only. GUID for active run. Blank if no active step(run) | {1C35029E-6929-4F65-B6EF-093FB4661D56} |
activestepduedate | Read-only. Duedate for active step. Blank if no active step | 2006-02-16 16:12:00 |
wfstatus | Read-only. Status of workflow instance. |
|
csstatus | Read-only. Current document status in Content Studio. Status are changed during the workflow. Values are defined in the definition. | New draft, Sent for review, Reviewed, Sent for approval, Approved |
perform_terminate_alias | Default alias for the user action 'terminate'. Used by some Active Scripting components. | Terminate workflow |
perform_setparticipants_alias | Default alias for the user action 'setparticipants'. Used by some Active Scripting components. | Select users... |
perform_changewfowner_alias | Default alias for the user action 'setparticipants'. Used by some Active Scripting components. | Change owner... |
adminsetwfowner_subject |
Message subject used when notifying (or mailing) the workflow owner when the action
'setwfowner' is performed. Supports wf_constants. |
The document $element_title has a new owner |
adminsetwfowner_msg |
Message used when notifying (or mailing) the workflow owner when the action 'setwfowner'
is performed. Supports wf_constants. |
The document $element_title has a new owner: $wfowner_fullname |
presetwfownersid |
SID of preset (predefined) workflow owner. If this parameter is set in the workflow
definition, the owner will alwas be set to presetwfownersid when the instance is
created. Supports wf_constants. |
S-1-5-21-2060480078-1251939488-620655208-1007 |
wfownersid | Read-only. SID of current workflow owner. | S-1-5-21-2060480078-1251939488-620655208-1007 |
wfownerfullname | Read-only. Fullname of current workflow owner | Niclas Astrom |
wfengineversion | Read-only. Engine version. For internal use only. | 1.1 |
initialcsstatus | Initial csstatus set when instance is created | New document, New Application, Draft, New Customer Request |
Roles section
This section defines roles and their default members.
Field/attribute | Description | Example |
---|---|---|
name | Name of role | Reviewers |
roletype | Type of role |
|
description | Role description | The reviewers can review the document |
Members section
The members section are part of each role section. One or more member can be defined. Note that additional members can be added in the category on which the definition is applied.
Field/attribute | Description | Example |
---|---|---|
source | Source of definition. If member is defined in the definition, the source attribute will be source. If the member is defined in the category, the source attribute will be category. |
|
membertype | Type of member |
|
sid | Security descriptor for member. | S-1-5-21-2060480078-1251939488-620655208-1007 |
userkey | Unique key for member. Each user in Content Studio has its own userkey | AAAAA2 |
name | Full name of member | Strandman Erik |
default | If yes, the member will default be added as an participant in steps where the role is used. |
|
notifyusing | Determines how members will be notified. |
|
Steps section
The steps section defines a number of steps. A step can be be an authoring step, a reviewing step or an approval step.
The steps definition is probably the most important and complex part of a workflow definition.
Field/attribute | Description | Example |
---|---|---|
name | Name of step |
For authoring, Under analys, Sale request |
stepid | Unique ID (integer) |
1 |
steptype | Type of step |
|
stepsettings | Step settings. Multiple values are permitted and must be separated with a comma (,) and a space. ex. allmustparticipate, csapprove |
|
stepdescription | A description of the step. Used in notifications and for information. | In this step content is created participants. Participants can edit and contribute until they return the document to the workflow owner. |
perform_send_alias | Alias for the user actions 'sendforxxxx'. Used by some Active Scripting components. | Send for authoring |
perform_yes_alias | Alias for the user actions 'yes'. Used by some Active Scripting components. | Return to workflow owner |
perform_no_alias | Alias for the user actions 'no' (reject). Used by some Active Scripting components. | Reject |
perform_decline_alias | Alias for the user action 'decline'. Used by some Active Scripting components. | Decline authoring request |
perform_cancel_alias | Alias for the user action 'cancelxxxxxx'. Used by some Active Scripting components. | Abort authoring |
wfownersettings | Settings that applies to the wfowner |
|
stepstart_subject |
Message subject used when notifying (or mailing) the workflow owner when the step
starts. Supports wf_constants. |
Authoring started on '$element_title' |
stepstart_msg |
Message body used when notifying (or mailing) the workflow owner when the step starts. Supports wf_constants. |
The document '$element_title' was sent for authoring to $allparticipant_names.$br$br($step_description)$csfooter |
csbeginstatus | Status set when the step starts | For authoring |
cscompleteyesstatus | Status set when the step is completed with a positive result (Yes/Approved). See completionrule | Authored |
cscompletenostatus | Status set when the step is completed with a negative result (No/rejected). See completionrule | Rejected |
cscancelstatus | Status set when the step is canceled by the wfowner | Authoring canceled |
csdeclinestatus | Status set when the step is declined | Authoring declined |
csduestatus | Status set when the step is due | Authoring is due |
selectable | Members participating in a role applied to a step, can be predefined or selectable by the workflow owner. |
|
serialflow |
Tasks assigned in a step can be assigned to participants in parallell or in serial:
|
|
minparticipants | Minimum number of participants | 1 |
completionrule |
A step has always a completion rule defining when the step is considered as complete. If the completion rule is forfilled, the step result will be completed. Normally the step result is evaluated everytime a task status changes and therefore the step can be completed BEFORE all participants have completed their tasks. If evaluation should occur AFTER all participants have completed/declied their tasks, the 'allmustparticipate' setting can be used.
|
20% |
completiondate | Read-only. Date of last completion | 2004-01-+2 |
taskduedate | Not used | |
duetime |
Absolute or relative date when the task is due. Leave blank if task is never due. For relative values, use DD,HH,NN where DD=days from now, HH=hours, NN=minutes Also supports valid .NET Timespan and DateTime values. Supports wf_constants. |
2,3,1 (2 days, 3 hours and 1 minute from now) 2.03:01:00 (2 days, 3 hours and 1 minute representated as TimeSpan) |
taskinstruction_subject |
Message subject used when notifying (or mailing) the participants when the step
starts. |
Authoring request on document '$element_title' |
taskinstruction_msg |
Message body used when notifying (or mailing) the participants when the step starts. |
Please help me author '$element_title'. $br$brComment: $comment $csfooter |
taskcomplete_yes_subject |
Message subject used when notifying (or mailing) the wfowner about the task completion. |
$element_title' authored by $Participant_FullName |
taskcomplete_yes_msg |
Message body used when notifying (or mailing) the wfowner about the task completion. |
I've contributed on document '$element_title'$br$brComment: $Comment$Br$BrParticipant(s) remaining: $allparticipant_assignednames $csfooter |
taskcomplete_no_subject |
Message subject used when notifying (or mailing) the wfowner about the task not
being completed. |
|
taskcomplete_no_msg |
Message body used when notifying (or mailing) the wfowner about the task not being
completed. |
|
taskcomplete_url | URL executed (httppost) when a task has been completed | http://wfserver/taskcomplete.asp |
taskcomplete_url_parameters | Parameters sent to URL. Supports wf_constants. | $element_title |
stepcompletion_yes_subject |
Message subject used when notifying (or mailing) the wfowner about the step completion
(positive/approve). |
Authoring completed on '$element_title' |
stepcompletion_yes_msg |
Message body used when notifying (or mailing) the wfowner about the step completion
(positive/approve). |
The document '$element_title' was authored by participants.$br$br$allparticipant_userssummary$csfooter |
stepcompletion_no_subject |
Message subject used when notifying (or mailing) the wfowner about the step completion
(negative/reject). Supports wf_constants. |
|
stepcompletion_no_msg |
Message bodyused when notifying (or mailing) the wfowner about the step completion
(negative/reject). Supports wf_constants. |
|
stepcompletion_declined_subject | Supports wf_constants. | Authoring declined: '$element_title' |
stepcompletion_declined_msg | Supports wf_constants. | The authoring on document '$element_title' was declined by participants.$br$br$allparticipant_userssummary$csfooter |
stepcompletion_due_subject | Supports wf_constants. | |
stepcompletion_due_msg | Supports wf_constants. | |
stepcomplete_url | URL executed (httppost) when the step has been completed. | |
stepcomplete_url_parameters | Parameters sent to URL. Supports wf_constants. | |
stepdue_url | URL executed (httppost) when the step is due. | |
stepdue_url_parameters | Parameters sent to URL. Supports wf_constants. | |
taskdue_subject |
Message subject used when notifying (or mailing) the participants about the task
being due. Supports wf_constants. |
|
taskdue_msg |
Message body used when notifying (or mailing) the participants about the task being
due. Supports wf_constants. |
|
onstepcomplete_yes | Stepname to automatically start if the step is completed (positive/approved). | |
onstepcomplete_no | Stepname to automatically start if the step is completed (negative/rejected). | |
onstepcomplete_declined | Stepname to automatically start if the step is declined. | |
onstepcomplete_due | Stepname to automatically start if the step is due. | |
onstartsetwfowner | SID. Set new workflow owner when the step starts. Supports wf_constants. | |
oncompleteyessetwfowner | SID. Set new workflow owner when the step is completed (positive/approved). Supports wf_constants. | |
oncompletenosetwfowner |
SID. Set new workflow owner when the step is completed (negative/reject).
Supports wf_constants. |
|
oncompletecancelsetwfowner | SID. Set new workflow owner when the step is declined by the workflow owner or an administrator. Supports wf_constants. | |
enablinglogic | Expression that enables or disables the step. Blank=always enabled. | NOT [@stepcomplete('For authoring')] |
notifywfownerusing | Type of notification used for workflow owner |
|
notifyparticipantsusing | Type of notification used for participants |
|
taskassigned_subject | Message subject used when notifying (or mailing) the workflow owner about the task being assigned on a participant. Supports wf_constants. | Authoring request sent to $participant_fullname |
taskassigned_msg | Message body used when notifying (or mailing) the workflow owner about the task being assigned on a participant. Supports wf_constants. | Authoring request on '$element_title' was sent to $participant_fullname.$csfooter" |
taskdeclined_subject | Message subject used when notifying (or mailing) the workflow owner about the task being declined by a participant. Supports wf_constants. | Authoring declined by $participant_fullname |
taskdeclined_msg | Message body used when notifying (or mailing) the workflow owner about the task being declined by a participant. Supports wf_constants. | Your request for authoring on '$element_title' was declined by $participant_fullname.$br$brComments: $comment$csfooter |
Steproles section within a <step>
Field/attribute | Description | Example |
---|---|---|
name | roles that can participate in the step | Authors |
Evaluation logic
The step tag 'enablinglogic' is a powerful mechanism for creating dynamic workflow. By using the evaluation logic, steps can be enabled and disabled depending on
- Completed steps
- XML-content
- User roles
- Other Workflow data
For the step to be enabled, the expression in the enablinglogic tag must be evaluated with a result different from False, 0 and blank. If it returns a value of True or anything else but the those mentioned, the step will be enabled and available for the workflow owner.
Expressions and functions
Function | Description | Example |
---|---|---|
[@memberofrole('rolename')] | Returns true if participant is a member of role rolename | [@memberofrole('editors')] |
[@stepcomplete('stepname')] | Returns true if the workflow step stepname has been completed | [@stepcomplete('Review')] |
$constantname | Returns the content of variable/constant constantname. | '$ept_department'='sales' |
Logical operators
- comparison: > < <> = <= >= (work also on strings)
- logical: and or xor not
Examples
- not [@memberofrole('editors')]
- not [@stepcomplete('Review')]
- ([@stepcomplete('QA')]) and ([@stepcomplete('Review')] or [@memberofrole('editors')])
- $ept_cost>2000
- '$ept_company'='Teknikhuset'
Constants, variables and functions for messaging
Using notifications and the workflow engine, messages can be sent using the internal messaging system and/or e-mail. When setting up the messages, the following constants can be used:
Constant | Description |
---|---|
$content | Inserts the document content |
$ept_xxx | Inserts the content of the xml-field xxx |
$wf_name | |
$wf_description | |
$wf_instanceguid | |
$wf_instancedbysid | |
$wf_instancedate | |
$wf_firststepdate | |
$wf_lastactiondate | |
$wf_lastactionparticipantsid | |
$wf_lastactionparticipantname | |
$wf_activesteptype | |
$wf_activestep | |
$wf_activerun | |
$wfsummary | |
$documentid | |
$categoryid | |
$categoryname | |
$revision | |
$wfownersid | |
$comment | |
$wfowner_domain | |
$wfowner_name | |
$wfowner_fullname | |
$wfowner_description | |
$wfowner_email | |
$wfowner_userkey | |
$run_started | |
$participant_sid | |
$participant_domain | |
$participant_name | |
$participant_fullname | |
$participant_description | |
$participant_email | |
$participant_comment | |
$participant_result | |
$participant_status | |
$participant_statusdate | |
$participant_assigneddate | |
$notificationid | |
$run_id | |
$run_statusdate | |
$run_status | |
$run_result | |
$run_started | |
$run_wfownercomment | |
$run_startedbysid | |
$run_duedate | |
$allparticipant_names | |
$allparticipant_sids | |
$allparticipant_assignednames | |
$allparticipant_assignedsids | |
$allparticipant_completednames | |
$allparticipant_completedsids | |
$allparticipant_declinednames | |
$allparticipant_declinedsids | |
$allparticipant_duenames | |
$allparticipant_duesids | |
$allparticipant_approvednames | |
$allparticipant_approvedsids | |
$allparticipant_rejectednames | |
$allparticipant_rejectedsids | |
$allparticipant_userssummary | |
$now | |
$newline | |
$br | |
$csfooter | |
$stepscompleted | |
$step_name | |
$step_type | |
$step_id | |
$step_description | |
$step_wfownersettings | |
$step_selectable | |
$step_serialflow | |
$step_completionrule | |
$step_completiondate | |
$step_taskinstruction_subject | |
$step_taskinstruction_msg | |
$step_taskdue_subject | |
$step_taskdue_msg | |
$step_settings | |
$element_title | |
$element_createddate | |
$element_publishdate | |
$element_archivedate | |
$element_modulename | |
$element_contenttype | |
$element_siteurllink | |
$element_csediturl | |
$document_revisioncreateddate | |
$document_revisioncreatedbyid | |
$document_revisioncreatedbydomain | |
$document_revisioncreatedbyname | |
$document_revisioncreatedbyfullname | |
$document_revisioncreatedbyemail | |
$document_revisioncreatedbydescription | |
$document_revisionmodifieddate | |
$document_revisionmodifiedbyid | |
$document_revisionmodifiedbydomain | |
$document_revisionmodifiedbyname | |
$document_revisionmodifiedbyfullname | |
$document_revisionmodifiedbyemail | |
$document_revisionmodifiedbydescription | |
$document_introduction | |
$document_url | |
$setting_siteurl | |
$setting_adminurl |